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Intellectual Property Rights 

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Media Content Distribution 
(MCD). 



Introduction 

Content Delivery Networks (CDN) are a solution to efficiently deliver content Consumers, including file-based and 
streaming video and multimedia content. An IPTV Service Provider uses CDN technology for content delivery to its 
own Consumer customers, see TS 182 019 [1]. A CDN Service Provider uses CDN technology to deliver content to 
Consumers on behalf of a Content Provider, see TR 102 688-9 [i.2]. 

Annex A of the present document presents several use cases where different CDN Service Provider would collaborate 
and interconnect to provide a better and more efficient CDN service to their Content Provider customers. Annex C uses 
the metaphor of newspaper distribution where Printer Companies collaborate to achieve a better and more efficient 
newspaper distribution service to Newspaper Companies. 

Based on those use cases, the present document specifies functional roles and CDN relationships, service requirements 
and technical requirements for CDN interconnection. 
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1 Scope 

The present document specifies the (stage- 1) service- and technical requirements for CDN interconnection services. The 
requirements are based on the use cases described in annex A of the present document. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http ://docbox . etsi . or g/Ref erence . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 182 019: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Content Delivery Network (CDN) Architecture". 

[2] ETSI TS 184 009: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Rules covering the use of TV URIs for the Identification of 
Television Channels". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] IETF Use Cases for Content Distribution Network Interconnection: draft-ietf-cdni-use-cases. 

NOTE: Available at http://tools.ietf.org/wg/cdni/draft-ietf-cdni-use-cases/ 

[i.2] ETSI TR 102 688-9: "Media Content Distribution (MCD); MCD framework; Part 9: Content 

Delivery Infrastructures (CDI)". 

[i.3] ISO/IEC 23009-1 :2012 "Information technology - Dynamic adaptive streaming over HTTP 

(DASH) — Part 1: Media presentation description and segment formats". 



3 Definitions and abbreviations 
3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

The following definitions are from TS 182 019 [1]: 

content delivery: act of delivering deployed content to a user 

Content Delivery Network (CDN): set of functions managing content acquired from content sources, through delivery 
to the user 
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content acquisition: act of acquiring content from a content source 

content deployment: act of moving ingested content to one or more network entities, based on content deployment 
policies 

content distribution: act of moving content in and between CDNs 

CDN interconnection: interconnection between two CDNs, enabling the controlled distribution of content between 
those CDNs 

The following definitions are from TR 102 688-9 [i.2]: 

content ingestion: act of introducing content (and associated data) into the Content Delivery Infrastructure 
segmented content: consisting of multiple mutually associated content files and/or - streams 

NOTE: The association between the segments are typically communicated through a manifest file. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 
CDN Content Delivery Network 

NOTE: Industry uses sometimes "Content Distribution Network". 



DRM 


Digital Rights Management 


FTP 


File Transfer Protocol 


GB 


GigaByte 


HAS 


HTTP-based Adaptive Streaming 


HTTP 


HyperText Transfer Protocol 


IPTV 


Internet Protocol Television 


OIPF 


Open IPTV Forum 


RTP 


Real-time Transport Protocol 


RTCP 


RTP Control Protocol 


SLA 


Service Level Agreement 


SVC 


Scalable Video Coding 


URI 


Uniform Resource Identifier 
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4 Overview of CDN interconnection services 



4.1 Functional roles and CDN Relationships 

For the purpose of the present document, concepts of domains, functional roles and CDN relationships are defined in 
this clause and are illustrated in figure 4.1.1. 
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Figure 4.1.1: Functional roles, domains and CDN Provider relationships 

for CDN interconnection 



Functional roles are defined with respect to a given delivery act (i.e. the actual delivery of a given piece of content to a 
given user at a given time). The functional roles are described as follows: 

The Ingesting CDN provider is the entity that ingests the content ("mastercopy") into the CDN Domain. It has a CDN 
interconnection with the Delivering CDN Provider (or a Transiting CDN Provider) that enables the controlled 
distribution of content from the ingesting CDN to the delivering CDN. 

The Delivering CDN provider is the entity that delivers the content ("consumable") into the Consumer Domain. It has 
a CDN interconnection with the Ingesting CDN Provider (or a Transiting CDN Provider) that enables the controlled 
distribution of content from the ingesting CDN to the delivering CDN. 

A Transiting CDN provider is an entity that distributes the content ("replica") from a CDN (that maybe the Ingesting 
CDN or a Transiting CDN) to another CDN (that may be the Delivering CDN or a Transiting CDN). For a given 
delivery act zero, one or more Transiting CDNs may be involved. 

NOTE: The terms "mastercopy", "replica" and "consumable" relate to the role of the content throughout the 
process (see also annex C). 

The Consumer is the entity where the content is consumed. The content is delivered through the CDN domain. 

The Content Provider is the entity that owns or is licensed to sell content or content assets. The content is delivered to 
a user through the CDN Domain. The Content Provider is authoritative with respect to control of consumer access to the 
content (i.e. whether a given delivery request from a consumer is to be honoured by the CDN domain or not). 
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The present document focuses on the CDN interconnection between CDN Providers collaborating to achieve content 
delivery. The present document defines the following relationships between two CDN Providers participating in a given 
delivery act: 

A CDN Provider is Upstream of another CDN Provider if the content is distributed from that CDN to the other CDN. 

A CDN Provider is Downstream of another CDN Provider if the content is obtained by that CDN from the other CDN. 

Because functional roles are relative to a given delivery act, in practice, a given entity may be performing more than 
one functional role. For example, a given administrative entity could be operating as the Ingesting CDN Provider for a 
given delivery act, operating as the Delivering CDN Provider for another delivery act and operating as a Transiting 
CDN Provider for yet another delivery act. Similarly, it could also be operating as the Content Provider or Consumer 
for some other delivery act. For the same reason, a CDN Provider that is Upstream of another CDN Provider for a given 
delivery act could be Downstream of this other CDN Provider for another delivery act, and may have no 
Upstream/Downstream relationship with that same other CDN Provider for yet another delivery act. 

The following business- and/or technical relationships are outside the scope of the present document. 

• Consumer - Content Provider: e.g. content selection and content purchase/rental 

• CDN Provider - Content Provider: e.g. content ingestion 

• Consumer - CDN Provider: e.g. redirection instructions and the actual content delivery 

4.2 MCD CDN Interconnection services 

4.2.1 General 

This clause describes CDN interconnection services at a high level. It focuses on the CDN interconnection services 
delivered between the Upstream CDN Provider and the Downstream CDN Provider. Services to the Consumer and 
Content Provider are outside the scope of the present document. 

4.2.2 Upstream CDN Provider CDN interconnection services 

The following is a list CDN interconnection services that could be provided by the Upstream CDN Provider. 

• Content acquisition and distribution services: 

Ingest or acquire content on behalf of a Downstream CDN Provider, in association with a Content 
Provider or Transiting CDN 

Distribute content to the Downstream CDN Provider, in association with a Content Provider 

• Delivery Control Services: 

Establish agreements on delivery attributes, with the Downstream CDN Provider 

Provide real-time control over ongoing deliveries, in association with the Downstream CDN Provider 

• Reporting services: 

Report on the distributed content to the Downstream Content Provider 

■ E.g. GB stored, GB distributed, traffic over time 
Support of reporting by the Downstream CDN Provider 

■ E.g. storage, processing and relay of reports to the content provider 

• Transit services 
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4.2.3 Downstream CDN Provider CDN interconnection services 

The following is a list CDN interconnection services that could be provided by the Downstream CDN Provider. 

• Content delivery services: 

Provide access for content distribution to the Upstream CDN Provider 
Deliver content on behalf of the Upstream CDN Provider 

• Delivery Control Services: 

Establish agreements on delivery attributes, with the Upstream CDN Provider 

Provide real-time control over ongoing deliveries, in association with the Upstream CDN Provider 

• Reporting services: 

Report on the delivered content to the Upstream CDN Provider 
■ E.g. GB stored, GB distributed, traffic over time 

• Transit services 

4.2.4 Guiding principle for CDN Interconnection 

Acceptance of CDN interconnection by the Content Provider is essential to successful deployment of CDN 
interconnection services. The following are guiding principles to highlight that the Content Provider is in control of 
anything that happens with or around the Content Provider's content within the interconnected CDN as if it were the 
Content Provider's own distribution network. Subject to business agreements between service providers, as well as local 
and regional regulatory requirements, in general, the principle of "as if it were the Content Provider's own distribution 
network" may apply to the following aspects: 

• Ownership of the content 

• Distribution of the content 

• Delivery of the content 

• Reporting on ongoing and past deliveries of the content 

• Guaranteeing the integrity of the Content Provider's content 

• Satisfying local and regional regulatory requirements on user privacy 

• Satisfying local and regional regulatory requirements on legal intercept 

4.3 Compliance 

A CDN interconnection solution is compliant to the present document if the following points are fulfilled. 

• All mandatory ("shall") services and features are implemented as specified in the associated architecture and 
protocol documents. 

• If an optional service ("should") or feature is implemented, then it is implemented as specified in the 
associated architecture and protocol documents. 

• If an optional service or feature is implemented, and the associated architecture and protocol documents 
specify multiple options, then it is implemented according to at least one or those options. 
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5 Service requirements 
5.1 General 

[5.1.1] The CDN interconnection shall enable controlled distribution of content between two CDNs. 

[5.1.2] The CDN interconnection shall support enforcement of the Consumer access control policy 

defined by the Content Provider. In other words, the CDN interconnection solution shall ensure 
that any delivery request is honoured, or rejected, in accordance with the access control policy 
defined by the Content Provider. The Content Provider access control policy may depend, in 
particular, on the content item, on the Consumer, on the Consumer location and on the request 
time. 



5.2 Service Types 

[5.2.1] The CDN interconnection solution shall support content distributions services required for file- 

based content (used e.g. for CoD) and stream-based content (used e.g. for Broadcast). 

[5.2.2] The CDN interconnection solution shall support delivery format adaptation in the downstream 

CDNs. 

NOTE: Delivery format adaptation includes, but is not limited to, conversion to adaptive streaming, the transport 
format conversion, code type conversion, content encapsulation conversion. 



6 Technical requirements 
6.1 General 

[6.1.1] The CDN interconnection solution shall be able to distribute content from an Upstream CDN to a 

Downstream CDN. 

[6.1.2] The CDN interconnection solution shall be able to distribute content from an Upstream CDN to 

multiple Downstream CDNs. 

[6.1.3] The CDN interconnection solution shall enable an Upstream CDN to push content to a 

Downstream CDN. 

[6.1.4] The CDN interconnection solution shall enable a Downstream CDN to pull content from an 

Upstream CDN. 

[6.1.5] The CDN interconnection solution shall enable the Downstream CDN to dynamically discover the 

content location information in order to pull content from an Upstream CDN in line with the 
content policy requirements by the Content Provider. 

[6.1.6] The CDN interconnection solution shall enable an Upstream CDN to delete content from a 

Downstream CDN, but only for content that was distributed by the Upstream CDN to the 
Downstream CDN. 

[6.1.7] The CDN interconnection solution shall support distribution and delivery of content transparently 

from its format, e.g. codec. 

NOTE: This does not exclude the possibility that content is transcoded in one of the CDNs, see clause 6.3. 

[6.1.8] The CDN interconnection solution shall be independent of the hardware or software of the content 

consumer. 

[6.1.9] The CDN interconnection solution shall be independent of the CDN technologies deployed by the 

Upstream CDN and the Downstream CDN. 
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[6.1.10] The CDN interconnection solution shall provide support for delivery format adaptation by the 

Downstream CDN according to the UE's capability and conforming to content policy and rights. 

[6.1.11] The CDN interconnection solution shall not implicate dependencies between the delivery 

mechanisms used by Upstream CDN and the Downstream CDN. 

[6.1.12] The CDN interconnection solution shall support that one CDN selects its Downstream CDN 

independently. 

[6.1.13] The CDN interconnection solution may support an arrangement where the Upstream CDN Service 

Provider agrees with a Downstream CDN Service Provider to use a specific CDN further 
downstream. 



6.2 CDN interconnection interfacing between Upstream CDN 
Provider and Downstream CDN Provider 

[6.2.1] The CDN interconnection solution shall have one or more technical interfaces for content 

distribution that enable streaming distribution of live and stored content. 

NOTE 1 : Examples of candidate interface for streaming content distribution is RTP/RTCP and HTTP. 

[6.2.2] The CDN interconnection solution should have one or more technical interfaces for request routing 

and content distribution of stream-based unicast content from Upstream CDN to Downstream 
CDN that enable the Downstream CDN to deliver the stream-based content (obtained from the 
CDN interconnection) through multicast to the Consumer. 

NOTE 2: Generally, multicast does not support reporting on connected users. An Upstream CDN could use 
client/player statistics instead. 

[6.2.3] For scenarios where the streaming content is pulled by the Downstream CDN in case of cache 

miss, the CDN interconnection solution should support a technical interface allowing the 
Downstream CDN to control the rate at which the streaming content is distributed to the 
Downstream CDN. 

[6.2.4] The CDN interconnection solution shall have one or more technical interfaces for content 

distribution that enable file transfer of stored content. 

NOTE 3: Examples of interfaces for file transfer are FTP and HTTP. 

[6.2.5] The CDN interconnection solution shall support transfer of segmented content between CDNs. 

The following types of segmented content shall be supported: 

• Content composed of multiple files. 

• Content composed of multiple streams. 

• Content composed of one or more files and one or more streams. 

NOTE 4: An example of content composed of multiple files is HTTP adaptive streaming. An example of content 
composed of multiple streams is tiled video, i.e. a high-resolution video composed of spatially separate 
lower-resolution video streams. Another example of content composed of multiple streams is scalable 
video coding (SVC). 

[6.2.6] The CDN interconnection solution shall support transfer of partial sets of individual content 

segments between CDNs. 

[6.2.7] The CDN interconnection solution should support efficient delivery of segmented content when 

different content segments are delivered from different CDNs. 

[6.2.8] The CDN interconnection solution shall allow interfaces between Upstream CDN and 

Downstream CDN to be realised over a managed network, e.g. a leased lined or a managed IP 
network. 
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[6.2.9] The CDN interconnection solution shall allow interfaces between Upstream CDN and 

Downstream CDN to be realised over an unmanaged network, e.g. the internet. 

[6.2.10] The CDN interconnection solution should allow one or more control-plane interfaces between 

Upstream CDN and Downstream CDN, for establishing agreement over desired delivery attributes 
among associated CDNs. 

NOTE 5: Examples of desired delivery attributes can be, but not limited to, reach ability/route characteristics, 
delivery related service level agreements, QoS attributes, performance thresholds, supported content 
lookup methods, content type and related attributes, supported failover abilities. 



6.3 Transcoding 



[6.3.1] The CDN interconnection solution shall support distribution of content that is transcoded or 

processed by the Upstream CDN. 

[6.3.2] The CDN interconnection solution shall support distribution of content that is transcoded or 

processed by the Downstream CDN. 

NOTE 1 : Transcoding or processing of content may be useful to make content better suited for distribution over 

access networks with a small bandwidth (e.g. a mobile network), or with an unknown and widely varying 
available bandwidth (e.g. the internet). 

NOTE 2: The transcoding or processing of content itself is not a requirement of the present document. 

6.4 CDN-I Security Requirements 

6.4.1 Integrity Requirements 

[6.4.1.1] The CDN interconnection solution shall enable the Upstream CDN to validate the integrity of the 

content. 

[6.4.1.2] The CDN interconnection solution shall enable the Downstream CDN to validate the integrity of 

the content. 

[6.4.1.3] The CDN interconnection solution shall assign unique and non-forgeable identities to all CDN 

content that are verifiable for users. The uniqueness shall be guaranteed for a period of time of 
more than one year. 

6.4.2 Authenticity Requirements 

[6.4.2.1] The CDN interconnection solution shall enable the Upstream CDN verify the authenticity of the 

source (origin) of content. 

[6.4.2.2] The CDN interconnection solution shall enable the Downstream CDN verify the authenticity of the 

source (origin) of content. 

[6.4.2.3] The CDN interconnection solution shall enable the Upstream CDN to authenticate communication 

from the Downstream CDN and vice versa. 



6.4.3 Authorization Requirements 



[6.4.3.1] The CDN interconnection solution shall enable access to requested content only to authorized 

users, subscribers and devices. 

[6.4.3.2] The CDN interconnection solution shall deny access to requested content by unauthorized users, 

subscribers and devices. 

[6.4.3.3] The CDN interconnection content protection functions shall provide a means for protecting time- 

restricted content usage. 
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[6.4.3.4] The CDN interconnection solution shall allow the Content Provider to explicitly authorize 

individual Consumer content request before it is honoured. In particular, this mechanism shall 
ensure that a Consumer cannot by-pass the Content Provider authorization even when the 
Consumer is aware of a content locator or identifier (e.g. URI) that has been used by that consumer 
before or by another Consumer (anti-deep linking). URL signing is a candidate mechanism to 
support this anti-deep linking requirement. 



4.4 Confidentiality Requirements 

[6.4.4.1] The CDN interconnection solution shall provide content confidentiality protection within 

regulatory constraints. 



4.5 Denial of Service Protection Requirements 

[6.4.5.1] The CDN interconnection solution shall have measures to detect Denial of Service (DoS) attacks 

posed upon the CDN interconnection solution. It should protect against Denial of Service (DoS) 
attacks to ensure fulfilment of the requirements of the Content Provider regarding timeliness and 
quality. 



4.6 Digital rights management (DRM) 

[6.4.6.1] The CDN interconnection solution shall support transparency to the DRM solution used by the 

Content Provider. 



[6.4.6.2] The CDN interconnection solution should be used for distribution of DRM keys. 

[6.4.6.3] DRM solutions supported by the CDN interconnection solution should include the key 

management, the delivery, and encryption and decryption operations of keys and content, and the 
corresponding interfaces. 

[6.4.6.4] The CDN interconnection solution should have content files and - streams encrypted throughout 

all CDN stages: ingestion, storage, distribution and delivery. 

NOTE 1 : The two above requirements do not directly impact the CDN, but they may impact the DRM solution 
used over the CDN. 



[6.4.4.5] The CDN interconnection solution should enable Content-Provider controlled-changing of the 

content encryption by the Upstream CDN and/or Downstream CDN. 

NOTE 2: There exist cryptographic systems that enable re-encryption of content without decrypting it. In such 
systems, the Content Provider would have to encrypt a piece of content only once, whereas each 
Consumer could receive a tailor-encrypted version of the content. As the Content Provider is in control of 
the keys, it can trust that the integrity and security of the content is maintained. 



5 Retrieving content identification 

[6.5.1] The CDN interconnection solution shall be compatible with the Consumer retrieving the content 

identification from the Content Provider. 

NOTE: The mechanism how the Consumer retrieves the content location is out of scope of the present document. 

[6.5.2] The CDN interconnection solution shall be able to support and resolve TV URI's for the 

identification of television channels, as specified in TS 184 009 [2]. 



6 Resolving content location 

[6.6.1] The CDN interconnection solution shall enable a Consumer to be redirected by the Content 

Provider to the Upstream CDN. 
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NOTE: Once the content is ingested into the CDN, there may be no need any more for this redirection. Typically 
the web site of a Content Provider has an object included that directly relates to the Upstream CDN. 

[6.6.2] The CDN interconnection solution shall enable a Consumer to be redirected by the Content 

Provider to the Downstream CDN. 

[6.6.3] The CDN interconnection solution shall allow an Upstream CDN Provider to select a Downstream 

CDN Provider to handle the request. When the selected CDN Provider is not the Delivering CDN, 
the CDN interconnection solution shall allow the selected CDN, in turn to select a Downstream 
CDN Provider, and so on until the selected CDN is the Delivering CDN. 

[6.6.4] The CDN interconnection solution shall not restrict the set of criteria that can be taken into 

account by the Upstream CDN Provider to select a Downstream CDN Provider. This shall include, 
and not be restricted to, the content item, the content type, the Consumer, the Consumer geo- 
location, time of day, tariffs of Downstream CDN, Downstream CDN performance, and 
administrative policy. 

[6.6.5] The CDN interconnection solution shall support CDN Provider loop prevention (e.g. to avoid a 

scenario where CDN Provider 1 selects CDN Provider 2 that selects CDN Provider 3 that selects 
CDN Provider 1). 

[6.6.6] The CDN interconnection solution shall enable a Consumer to be redirected by the Upstream CDN 

to the Delivering CDN Provider. This applies both in the absence of Transiting CDN Provider and 
in the presence of one or more CDN Transiting Provider(s). 

[6.6.7] The CDN interconnection solution shall support an optional mechanism to limit the number of 

transiting CDNs involved in the request redirection. 

[6.6.8] The CDN interconnection solution shall support an optional crank-back mechanism in case the 

Downstream CDN Provider selected by the Upstream CDN Provider cannot handle the redirection. 
This allows the Upstream CDN to select another Downstream CDN (or itself) to honour handle the 
request. 

[6.6.9] The CDN interconnection solution shall be compatible with the Upstream CDN Provider 

retrieving the content location from the Downstream CDN Provider. 

6.7 Reporting 

[6.7.1] The CDN interconnection solution shall enable the Downstream CDN Provider to provide status 

report on identified content to the Upstream CDN Provider. 

[6.7.2] The CDN interconnection solution shall enable the Upstream CDN Provider to retrieve status 

reports on identified content from the Downstream CDN Provider. 

NOTE 1: Examples of status of identified content are "receiving", "preparing", "ready for delivery", "Ingesting", 
"unavailable", "deleted" and "unknown". 

[6.7.3] The CDN interconnection solution shall enable the Downstream CDN Provider to provide detailed 

transaction logs on identified content to the Upstream CDN Provider for deliveries performed on 
behalf of that Upstream CDN Provider. 

[6.7.4] The CDN interconnection solution shall enable the Upstream CDN Provider to retrieve detailed 

transaction logs on identified content from the Downstream CDN Provider for deliveries 
performed on behalf of that Upstream CDN Provider. 

NOTE 2: Examples of transaction logs information, for each delivery, include content identifier, start time, finish 
time, and delivery quality indicators (resolution, bandwidth, loss, etc.). 
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[6.7.5] The CDN interconnection solution should allow one or more control-plane interfaces between 

Upstream CDN and Downstream CDN for achieving real-time monitoring and control over on- 
going delivery. 

NOTE 3: Examples of real-time control over on-going delivery may lead to, but not limited to, following 
capabilities. 

• Real-time congestion awareness 

• Dynamic bandwidth allocation 

• Real-time QoS control 

• Dynamic content adaptation 



6.8 Topology and topology hiding 

[6.8.1] The CDN interconnection solution shall enable the Upstream CDN Provider to push content to an 

identified CDN delivery node in the Downstream CDN. 

[6.8.2] The CDN interconnection solution should enable the Downstream CDN Provider to provide the 

relevant content deployment capabilities to the Upstream CDN, such that the Upstream CDN can 
redirect a content delivery request from a Consumer directly to an identified CDN node. 

[6.8.3] The CDN interconnection solution shall enable a Downstream CDN to hide its topology to the 

Upstream CDN and present itself as a single CDN node, or as a set of such, e.g. one per CDN 
interconnection interface. 
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Annex A (informative): 

CDN Interconnection use cases 

A.1 General 

This annex provides a set of use cases to illustrate the application of CDN interconnection. The functional roles and 
CDN Provider relationships from clause 4.1 (Content Provider, Consumer, Ingesting CDN Provider, Delivering CDN 
Provider, Transiting CDN, etc.) are used where appropriate. 



A.2 Consumer use cases 
A.2.1 Popular global content 

The soccer world cup is watched "live" by Consumers all over the world. Moreover, Consumers start browsing through 
the highlights of a match on a massive scale. CDN interconnection between CDN Providers world-wide makes sure that 
the global network will not suffer from large scale simultaneous delivery and changing traffic patterns and that all 
Consumers can see the streams and clips that they request to see, within the agreements between the CDN operator and 
network operator. 

A.2. 2 Popular remote content 

Annually, the Spanish island of Mallorca is visited by many German tourists, who watch German TV channels and 
German videos on a large scale. CDN interconnection between a German CDN Provider and a local Spanish CDN 
provider can make sure that all tourists can see the streams and videos of their choice with suitable quality of 
experience. 

A.2. 3 Quality Improvements Derived from IETF draft [i.1] 

Some existing CDN Service Providers make the decision to work with ISPs to deploy surrogates closer to the end users. 
Compared to alternatives such as adding capacity at major peering points, this method offers better experience to the 
end users. Some Content Providers are willing to pay a premium for such enhanced service rather than just using the 
CDN Service Provider to mitigate their server and network access costs. Improved experience may be provided by 
closer proximity to the end users. It could also involve network characteristics, such as provisioning or QoS, and 
specific delivery techniques such as encoding for constant Quality of Experience. 

A.2. 3.1 Network Service Provider CDN Service Provider Use Case 

In an interconnection use case, CDN Service Provider-A is likely to offer an SLA to the Content Provider (CP) 
including performance or other quality metrics. If it cannot meet the SLA it will push content via the interconnection to 
a CDN Service Provider-B with CDN capabilities that are in a position to guaranty the SLA, and redirect users 
appropriately to CDN Service Provider-B. CDN Service Provider-A may not be able to, or may not wish to deploy its 
own CDN capabilities to meet the SLA requirements for only a subset of customers. The ability to offer stringent 
delivery quality SLAs is a differentiator against other CDN Service Providers and can be sold as a premium service. 
Although this use case has similarities to extending geographic reach, in this case it is expected that the CDN Service 
Provider does have a CDN deployed which could effectively serve content to the end-users, but wishes to increase 
quality of experience for specific CPs. 
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A.2.4 Offload use cases derived from IETF draft [i.1] 
A.2.4.1 Overload handling and dimensioning 

The support of prime-time traffic load may require over-dimensioning the CDN capacity. In addition unexpected spikes 
in content popularity may drive load beyond the expected peak. As prime time and peaks of content distribution may 
differ between two CDNs, a CDN may interconnect with another CDN to increase its effective peak capacity. Similarly, 
two CDNs may benefit from dimensioning savings by using the resources of each other during their peaks of activity. 

The profile of activity peaks (time, duration, etc.) differ not only from one country to another but also according to the 
kind of CDNs. Therefore, CDN interconnect will be required since the additional capacity is likely to be provided by 
alternative technology. Offload also applies to planned situation where a CDN Service Provider needs CDN capacities 
in a particular region during a short period of time. For example, during a specific maintenance operation or for 
covering the distribution of a special event, such as an international sport competition. 

A.2.4. 2 Resilience 

It is important for CDNs to be able to guarantee service continuity during partial failures (e.g. failure of a set of CDN 
components). In partial failure scenarios, a CDN Service Provider could redirect some requests toward another CDN. 
This downstream CDN would be able to serve the redirected requests or, depending on traffic management policies, to 
forward these requests to the appropriate server. 

Resiliency may also be required against failure to ingest content from the CP. In these cases the content may be 
available from another CDN Service Provider. 

A.2.5 Footprint Extension Use Cases Derived from IETF draft [i.1] 
A.2.5.1 CDN Interconnection inside one CDN Service Provider 

A large CDN service provider operates the CDNs of a set of subsidiaries from different countries, and these CDNs can 
rely on different CDN solutions. To provide a consistent service to his customers on its whole footprint, in certain 
circumstances, the CDN service provider needs to make its CDNs intemperate . 

Note that currently, the distribution of some content is restricted. For instance, distribution rights for audiovisual content 
are often negotiated per country. 

A.2.5. 2 CDN Interconnection between CDN Service Providers 

Several CDN service providers have a geographically limited footprint (e.g. a country), or do not serve all end-users in 
a geographic area. Interconnecting CDNs enables CDN Service Providers to provide their services beyond their own 
footprint by relying on other CDNs. 

End-users in various countries access TV shows episodes. The Content Provider that distributes the TV show asks a 
French CDN Service Provider to deliver the serial to several countries. The French CDN Service Provider makes an 
agreement with an external CDN Service Provider that covers North Africa to provide a CDN service for France and 
North Africa. 

This use case applies to other types of contents like automatic software updates (browser updates, operating system 
patches, or virus database update, etc.). 

A.2.6 Popular segments 

The following use cases are examples of segmented content, where some segments are much more popular than other 
segments. 
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A.2.6.1 Popular time segments 

A new video clip becomes available. Many Consumers start watching the clip, but most stop watching after ten seconds 
as they find it not sufficiently interesting. 

A guru recommends a section of a video clip through social media. Many of his followers start watching the 
recommended section, but they do not watch the rest of the video. 

A.2.6.2 Popular video tiles 

A major soccer match is distributed as tiled video. Most Consumers watch only the central tiles with the soccer players 
and the field. Only a happy few consumers with big high-resolution screens request the tiles of the surrounding area. 

A.2.6.3 Scalable and multi-rate video 

A movie is made available in a scalable video coded format (SVC). Many Consumers watch the movie on a mobile 
device, and they request only the low-resolution based layer. Consumers with higher-resolution screens and higher- 
bitrate connectivity also request the high-resolution enhancement layers. 

A movie is made available in multiple bitrates. Consumers attached to a mobile network request only the low-bitrate 
version. Consumers with fixed higher-bitrate connectivity request the high-bitrate version with better quality. 



A.3 Topology use cases 
A.3.1 Primary and secondary CDN 

In this use case, a Consumer contacts the primary CDN for the content. The primary CDN can decide to deliver the 
content directly to the Consumer, and act as Delivering CDN Provider. It can also redirect the request for content 
delivery to the secondary CDN that will take the functional role of Delivering CDN Provider. The primary CDN 
provider has its own criteria for this decision, for example be load/performance related or based on the geographical 
location of the Consumer. There can also be multiple secondary CDNs. 

A.3.2 CDN Peering 

With a bilateral agreement, two CDN providers can agree to use each other's CDNs for specified sets of Consumers. So 
when the content in the domain of CDN A is to be delivered to a Consumer in the domain of CDN B, the content 
request to CDN A is redirected to CDN B. And vice versa. This is typically used, but not limited, in case of access 
providers with CDNs that are contracted by a Content Provider to distribute and deliver content beyond their own 
domain. CDN peering would reduce the traffic between those access providers. 

A.3.3 CDN Federation 

In this use case, several (more than 2) CDN Providers agree to use each other CDNs for distributing content in the most 
optimal way. Consumer requests to a CDN will be redirected to the CDN in the federation that is best positioned to 
deliver the content to the Consumer. This makes it possible for the federated CDN providers to act as a global (or 
regional) CDN. 
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A.3.4 More than two CDN hierarchy 

In this use case, the Consumer request is forwarded by the primary CDN (the Ingesting CDN) to a secondary CDN (a 
Transiting CDN), which decides that the content can be better delivered by a third CDN (the Delivering CDN) and thus 
redirects the request to this third CDN. Though there may be practical limitations to the number of CDNs involved in a 
given delivery act redirect (like end-user performance/response); these should not be limitations in the specifications. 

NOTE 1 : This use case does not refer to possible internal forwarding processes within a CDN internally. 

NOTE 2: CDN federation would be an alternative to this use case by including the third CDN in the primary CDN 
decision-making process. 

A.3.5 CDN to multicast 

In this use case, the CDN that should deliver the content to the Consumer has capabilities to transfer the content to a 
multicast capable network. This only works for content that is distributed simultaneously to multiple users e.g. live 
streaming/linear content. This could result in an additional reporting model. 

A.3.6 Segmented content 

In this use case, the Upstream CDN Service Provider distributes segmented content (files and/or streams) to the 
Downstream CDN Service Provider. Because of the pricing model of the Downstream CDN Service Provider, the 
Upstream CDN Service Provider can only profitably have the most popular segments (see clause A.2.6) delivered by 
the Downstream Service Provider to Consumers. Moreover, the Upstream CDN Service Provider has sufficient 
transport and delivery capacity to deliver the less popular segments directly to Consumers requesting those, without 
needing to invoke the Downstream CDN Service Provider. Therefore, the Upstream CDN Service Provider distributes 
only some of the segments to the Downstream CDN Service Provider, but not all. The CDN interconnection solution 
assures the efficient and timely delivery of segments to the Consumers from both CDNs. 



A.4 Other use cases 

A.4.1 Delivery Format Adaptation 

Before content can be delivered to a user, there might be the need to transform its delivery format prior to delivery. 

One possible realisation is that the delivering CDN which is nearest to the UE performs such delivery format adaptation 
according to the UE's capabilities. Delivery format adaptation may include, but is not limited to, conversion to adaptive 
streaming, the transport format conversion, codec type conversion, content encapsulation conversion and content 
metadata conversion (e.g. content description, program information, etc.). 

For example, content is delivered from Content Provider through CDN-A and CDN-B to the CDN-C in the form of a 
normal RTP stream. The delivering CDN, CDN-C, determines that a UE requires the content to be delivered using 
adaptive HTTP streaming, CDN-C now performs delivery format adaptation and transforms the RTP stream to an 
adaptive HTTP stream that can be delivered to the UE. 
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Figure A.4.1.1 : Example of Delivery Format Adaptation 



A.4.2 Support for HTTP Adaptive streaming 

Future CDNs require better support for media streaming service. HTTP Adaptive streaming (HAS) is a promising 
solution for efficient and high-quality delivery of streaming services over the Internet, which supports re-use of existing 
infrastructure and technologies. HAS has received extensive attention, and different solutions have emerged from 
industry (e.g. Microsoft Smooth Streaming, Apple HTTP Live Streaming) as well as standardization bodies 
(e.g. MPEG-DASH [i.3]), and therefore HAS in a multi-CDN scenario is an important consideration. 

NOTE: Activity is in progress which may lead to convergence of 3GP-DASH and OIPF HAS into the MPEG- 
DASH solution. 

CDN-I architecture could support the deployment of HAS solution. The Content Provider distributes the content to the 
consumers through multiple CDNs providing ingesting, transiting and delivering services. In the case of HAS, the 
origin server hosts the media segments and the manifest file that includes the segments' URL in the CDN domain. The 
CDN caches the media segment and manifest, and interconnects with downstream CDNs. 

The CDN interconnection could enable the following techniques (non-exhaustive list): 

• URL rewriting: downstream CDN rewrites the URLs in the manifest file that are pointing to the media 
segments. Therefore the requests sent by the clients to get the media segments will follow the CDNI request 
routing process and be directly handled by the appropriate downstream CDN. The downstream CDN would 
have all information required to acquire the media segments from upstream CDN in case of cache miss in its 
network. This URL rewriting procedure could help reducing latency from client viewpoint, and network load 
(avoid handling all client requests for media segments in upstream CDN). 

• Transcoding: It is not always possible for the downstream CDN to directly handle and distribute media 
segments from the upstream CDN. For example, when video codec/resolution/bitrate requested by the client 
cannot be directly fulfilled by the replica from uCDN. In this case, dCDN needs to transcode the content. The 
downstream CDN transcodes the content according to its agreement with upstream CDN and its own 
capability. It could generate media segments with new file format and new video parameters (bitrate, frame 
rate, resolution, etc.) The downstream CDN acquires necessary information such as capability, resources and 
policies through CDNI control and metadata interfaces. The transcoding operation could optimize the 
resources utilization for CDN and the quality for clients. 
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Annex B (informative): 
Architectural approaches 

B.1 Generic architecture for CDN interconnection 

Figure B.l.l shows a generic architecture for CDN interconnection. 



Consumer CDN Content 

Domain Domain Domain 




Figure B.1.1 : Generic architecture for CDN interconnection 

The Consumer, CDN Providers and Content Providers are connected via one or more IP network(s) (e.g. the Internet). 
Each CDN can have similar internal distribution interfaces. Content can be: 

• on-demand; 

• linear (typical live); 

• streaming; 

• progressive download. 

DRM is regarded as a function of the content, so the architecture is indifferent for DRM.The internal working of the 
CDNs and QoS optimizations in the IP networks are out-of-scope. 

The following architectural reference points could be identified. Each of these could be implemented by zero, one or 
more protocol interfaces. The focus of CDN interconnection is on the CDNcc reference point between any two CDN 
Providers participating in CDN interconnection. 

• CDNui: Reference point between User Equipment and Ingesting CDN: 

Content request 
Connection test 

Redirection to Delivering CDN 
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• CDNcc: Reference point between Upstream CDN Provider (Ingesting CDN or Transiting CDN Provider) and 
Downstream CDN Provider (Delivering CDN or Transiting CDN Provider): 

Content distribution, push and/or pull. 

Content deletion 

System status 

Content location 

Content status reporting 

Content transaction logs reporting 

• CDNud: Reference point between User Equipment and Delivering CDN: 

Content request 
Content delivery 

• CDNic: Reference point between Ingesting CDN and Content Provider system (out of scope): 

Content acquisition 
Content ingestion 
System status 
Content status reporting 
Content usage reporting 

• CDNuc: Reference point between User Equipment and Content Provider System (out of scope): 

Metadata request (e.g. web page retrieval) 
Metadata delivery (e.g. web page delivery) 

Content request (in case the metadata did not provide the redirect) 
Redirection to Ingesting CDN and/or Delivering CDN 

B.2 Example procedure for a content request 

Figure B.2.1 shows an example of a procedure for a content request in the case where there is no transiting CDN 
Provider and where distribution is performed on request from the Downstream CDN (i.e. Pull). 
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Figure B.2.1 : Example procedure for content request 

1) The user equipment retrieves metadata that enables it to send out a content request, e.g. from a website or 
electronic program guide provided by the Content Provider system or by the Ingesting CDN. 

2) The user equipment sends a content request to the Ingesting CDN. The requested content is typically identified 
by a URL 

3) The Ingesting CDN has an option to get additional information for the user equipment and its access 
connection to the Ingesting CDN. Examples of such information are user equipment geo-location and 
broadband access provider. This information might be obtained through a query to a local database, a remote 
database (e.g. from a geo-location service provider). 

NOTE: The Ingesting CDN may be able to deliver the content to the user equipment directly, but that is not 
relevant to this procedure example. 

4) The Ingesting CDN Provider may have agreements with several Downstream CDN Providers. In accordance 
with its decision criteria and policy, the Ingesting CDN Provider selects the Downstream CDN Provider for 
this particular content delivery. 

5) The Ingesting CDN Provider issues a query to the Downstream CDN Provider requesting a content location 
identifier (towards which the user is to be redirected). 

6) In accordance with its decision criteria and policy, the Downstream CDN Provider selects itself as the 
Delivering CDN Provider. 

7) The Delivering CDN Provider runs internal procedure to identify which cache is to be used to perform this 
particular delivery and returns the corresponding content location information (e.g. a URI) to the Upstream 
CDN (that is also the Ingesting CDN Provider in this case). 

8) The user equipment is instructed to retrieve the content from the Delivering CDN Provider using the specific 
content location information provided to the Ingesting CDN Provider by the Delivering CDN Provider in 
step 7. HTTP redirect is one of the possible mechanisms to achieve this. 

9) The user equipment sends a content request to the Delivering CDN Provider. 
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10) The Delivering CDN performs request authorization checks in accordance with the content access policy of 
the Content Provider. For example, this may not involve explicit checks (e.g. when content is to be made 
freely available) or may involve local validation (e.g. URL signing validation) or may involve 
validation/authorization from Content Provider (e.g. cache freshness validation). 

11) If the content is already available in the Delivering CDN Provider (e.g. because it is stored content and has 
been pushed by the Upstream CDN Provider or has been pulled by the Delivering CDN Provider earlier, or 
because it is linear content already being distributed), the Delivering CDN directly jumps to step 12. Otherwise 
the content needs to be distributed to the Delivering CDN by its Upstream CDN (i.e. the Ingesting CDN in this 
scenario). In case of stored content, the Delivering CDN Provider issues a content distribution request to its 
Upstream CDN Provider as illustrated in figure B.2.1. 

12) The Ingesting CDN Provider distributes the content to the Delivering CDN. 

13) The Delivering CDN starts delivering the content to the user equipment (typically in parallel to receiving the 
rest of the content from its Upstream CDN). 



Usage equipment information is collected and distributed in the following way: 

• The Delivering CDN collects usage information based on content delivery, including start time, finish time, 
gigabytes transferred, pause/stop/play stream, delivery speed, quality parameters. 

• The Delivering CDN provides usage information to each of its Upstream CDN Provider (for the deliveries that 
had been delegated to it by that Upstream CDN Provider). 

• Each CDN Provider receiving usage information from Downstream CDN Providers aggregates those. If the 
CDN Provider is a Transiting CDN Provider it provides usage information to each of its Upstream CDN 
Provider (for the deliveries that had been delegated to it by that Upstream CDN Provider). 

• A Transiting CDN Provider and pass on usage information Ingesting CDN. 



Figure B.4.1 provides an alternative view on the CDN interconnection architecture, highlighting the positioning of 
access and transport networks. There is often a direct relationship between the Delivering CDN and the access network 
to which the user equipment is connected. 



B.3 Usage information 



B.4 



Access networks in the CDN architecture 
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Figure B.4.1 : Architecture view, highlighting access and transport networks 



B.5 Procedure for content distribution 

Figure B.5.1 shows a procedure for a content distribution in the case that Ingesting CDN distributes content to 
Delivering CDN (i.e. Push mode) actively. When a new content was released, the content provider may ingest the 
content to ingesting CDN instead of all of the delivering CDN. As agreement between Ingesting CDN (up streaming 
CDN) Provider and Delivering CDN (Down streaming CDN) Provider, the former could distribute the new content to 
delivering CDN according some policy. And then the content could be distributed inside Delivering CDN. If end user 
discovers this new content, the end user could request the content in the delivering CDN and of course the Delivering 
CDN could handle this request. 
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Figure B.5.1 : Procedure for content distribution 
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Precondition: The Ingesting CDN Provider has agreements with Delivering CDN Providers. When a media new content 
was published or updated, the Ingesting CDN provider could distribute it to delivering CDN for user consuming. 

1) The content provider ingests a new content to Ingesting CDN. 

2) The Ingesting CDN issues a Notification message to Delivering CDN to notify the new media content 
published or updated, the metadata information could be carried in this Notification message. 

3) The Delivering CDN send Content Distribution Request message to Ingesting CDN to request setup media 
content distribution dialogue. 

4) The Ingesting CDN answer back Content Distribution Response message to Delivering CDN to confirm the 
setup of media content distribution dialogue. 

5) The media distribution dialogue established and the media content distributed between Ingesting CDN and 
Delivering CDN (e.g. some schemes could be selected for the media distribution dialogue, such as FTP, 
HTTP, etc.). 

6) The Delivering CDN receives distributed media content via media distribution dialogue scheme and stores the 
media content (such as with files) in its local storage unit. 

7) The Delivering CDN feeds back Content Distribution Acknowledge message to Ingesting CDN, when the 
content distribution dialogue finished. 

8) The Delivering CDN checks the metadata structure and transform it if the metadata from Ingesting CDN is 
different with its own metadata structure (Metadata Adaptation). 

9) The User Equipment send Content Delivery Request message to Delivering CDN to request media content. 

10) The Delivering CDN handles this request and response back media content with Content Delivery Offering 
message to User Equipment. 

11) The delivering CDN record and make the content usage statistics, and report the statistics result to Ingesting 
CDN using Content Report message, when the media content was requested and consumed by end users. 



B.6 Content delivery through CDN Interconnection 

With the CDN interconnection, the content may be delivered from the Content Provider to the target consumer (UE) 
through multiple CDNs. As a simplest example, the content may be delivered from CP through multiple CDNs one by 
one towards the consumer(UE), see figure B.6.1 showing an example of content ingestion, distribution and delivery 
through CDN Interconnection. Meanwhile, one CDN may need to duplicate and distribute the content to its multiple 
downstream CDN or Ues, see figure B.6. 2 showing an example of content distribution to multiple CDNs through CDN 
Interconnection. In this example, CDN-A requires CDN-B to deliver content to UE-x and requires the CDN-G to 
deliver content to both UE-y and UE-z. 

For these two examples, the content distribution an delivery from the Content Provider to the Consumer includes 
multiple processes (e.g. the process between Content Provider and CDN-A is for the content ingestion; the process 
between CDN-A and CDN-B is for the content distribution; the process between CDN-C and Consumer is for the 
content delivery) and will be specified in later stage work. 



Content 
Provider 




CDN-A 





CDN-B — • — 



CDN-C 



Consumer 



Figure B.6.1: Content ingestion, distribution and delivery through CDN Interconnection 
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Figure B.6.2: Content distribution to multiple CDNs through CDN Interconnection 
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Annex C (informative): 

A metaphor for the electronic content delivery ecosystem 
C.1 General 

This annex provides a metaphor for the electronic content delivery ecosystem to provide a better understanding of roles 
and relationships in this ecosystem. The metaphor of a newspaper distribution ecosystem was chosen, as that ecosystem 
is well understood and it has many aspects in common with content delivery. Of course, any metaphor should be used 
with care, as there will always be (subtle) differences. 

Table C.l.l gives an overview of roles and concepts from the newspaper distribution ecosystem and their equivalents 
from the content delivery ecosystem. Clauses C.2 and C.3 provide highly similar descriptions of the two ecosystems to 
highlight some of their equivalences, including an equivalence for CDN interconnection. 



Table C.1.1 : Equivalences between newspaper distribution and content delivery 



Newspaper Distribution 


Content Delivery equivalents 


News (for newspapers) 


Content (for electronic delivery) 


Printing plates 


Mastercopy (of the content) 


Replica plates 


Replica (of the mastercopy of the content) 


Newspaper 


Consumable (content) 


Newspaper Company 


Content Provider 


Newspaper Reader 


Content Consumer 


Printer Company 


CDN Service Provider 


Postal Company 


Network Service Provider 


Newsstand Company 


IPTV Service Provider 



C.2 The newspaper-distribution ecosystem 

The business of Newspaper Companies is to generate and/or collect news items and other articles, and bring those 
together into newspapers. The audience for the newspapers are Newspaper Readers. Different Newspaper Companies 
may have different business models, including subscription-based, advertising-based, combinations of those and other. 

Getting the newspapers to the Newspaper Readers is essential to the Newspaper Company. Some Newspaper 
Companies may have their own printing presses, trucks to move the printed newspapers, outlets for Newspaper Readers 
to pick up the newspapers, and personnel to get newspapers delivered to mailboxes of Newspaper Readers. However, 
Newspaper Companies may also decide to outsource some or all of those newspaper-distribution activities to 
specialised companies. 

• Printing Companies have one or more printing presses to print newspapers. 

• Postal Companies have one or more trucks and personnel to move and deliver printed newspapers. 

• Newsstand Companies have one or more newsstands where people can pick up newspapers. 

In practice, players in the newspaper-distribution ecosystem may take multiple roles. Some companies may have 
printing presses, but some delivery trucks as well. Some companies may have newsstands, but delivery personnel as 
well. Also, some companies may specialize, e.g. to global or local delivery, high quality colour print or bulk black-and- 
white, specialized shops, etcetera, whereas other companies may generalize and cover as many aspects of newspaper 
(distribution) business as they can. 

Figure C.2.1 sketches a newspaper-distribution ecosystem. 
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Figure C.2.1 : Sketch of a newspaper-distribution ecosystem 



Ecosystem invisible to Newspaper Reader 

The whole newspaper distribution ecosystem is opaque to the Newspaper Reader. The only thing that the Newspaper 
Reader has to know is that he can pick up newspapers from a newsstand or get them delivered to his mailbox. Some 
newspapers may be for free, others may be paid per print and it may also possible to subscribe (and unsubscribe) to 
newspapers. 

Newspaper Company in control 

As the Newspapers Company pays for the printing, distribution and delivery services of the other companies in the 
ecosystem, the Newspaper Company can set some requirements. Newspaper Companies may want to know how many 
newspapers are printed, the qualities of the printed newspapers, to where they are distributed, the timeliness of the 
printing and delivery, assurance that no illegal copies are printed or distributed, that old newspapers are destroyed, 
etcetera. Of course, the precise requirements of a Newspaper Company will vary depending on its particular business 
model. 



News neutrality 

Neutrality of newspaper-distribution is important to the Newspaper Company. No player in the ecosystem should 
modify articles, change styles and fonts, insert advertisements or change anything similar without explicit consent from 
the Newspaper Company. These types of requirements are typically agreed in Service-Level Agreements with the 
Newspaper Company. 



Distribution neutrality 



Neutrality of newspaper-distribution is also important to the Newspaper Readers. Players in the newspaper-distribution 
ecosystem should not misuse an acquired or natural monopoly on aspects of the delivery to unfairly discriminate other 
players. For example, a company that happens to have a local monopoly on postal services should not be allowed 
prohibitive pricing the delivery of newspapers composed and/or printed by other companies. This type of requirements 
are typically regulated by law and maintained by an independent regulator and/or competition authority. 
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Collaborating Printing Companies 

Although Printing Companies are typically each other's competitors, there are also cases where Printing Companies 
may want to collaborate. Here are some examples. 

• A Printing Company may have insufficient printing-press capacity to handle a special event or a specific large 
order. The Printing Company could commission the capacity of other Printing Companies as back-up for such 
occasions. 

• A global Printing Company could commission a local Printing Companies to locally print newspaper in order 
to achieve more cost-efficient newspaper distribution in a specific region. 

• Local Printing Companies could team up and have a joint venture to increase their distribution footprint, 
competing with global Printing Companies over large Newspaper Company account. 



C.3 The content-delivery ecosystem 

The business of Content Providers is to generate and/or aggregate digital content items, and bring those together into 
content (programs, TV channels, etc.). The audience for the consumable content are Content Consumers. Different 
Content Providers may have different business models, including subscription-based, advertising-based, combinations 
of those and other. 

Getting the content as consumable content to the Content Consumers is essential to the Content Provider. Some Content 
Providers may have their own content delivery servers, a network to transport the content, web shops for Content 
Consumers to obtain the content, and solutions to get content delivered to the homes of Content Consumers. However, 
Content Providers may also decide to outsource some or all of those content -delivery activities to specialised 
companies. 

• CDN Service Providers have one or more servers for streaming and downloading consumable content from. 

• Network Service Providers have a network to transport mastercopies, replicas of the content and to deliver 
consumable content. 

• IPTV Service Providers have services enabling people to consume the content: i.e. to watch TV channels and 
to obtain content on demand. 

In practice, players in the content delivery ecosystem may take multiple roles. Some companies may have servers, but 
some network as well. Some companies may have web shops, but a subscription service as well. Also, some companies 
may specialize, e.g. to global or local delivery, guaranteed delivery or best-effort delivery, etcetera, whereas other 
companies may generalize and cover as many aspects of content (delivery) business as they can. 

Figure C.3.1 sketches a content-delivery ecosystem. 
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Figure C.3.1 : Sketch of a content-delivery ecosystem 

Ecosystem invisible to Content Consumer 

The whole content delivery distribution ecosystem is opaque to the Content Consumer. The only thing that the Content 
Consumer has to know is that he can obtain consumable content from a web shop or get an IPTV service. Some 
consumable content may be for free, others may be paid per view and it may also possible to subscribe (and 
unsubscribe) to consumable content. 

Content Provider in control 

As the Content Provider pays for the delivery, transport and retail services of the other companies in the ecosystem, the 
Content Provider can set some requirements. Content Providers may want to know how many times the content was 
consumed, the quality of the delivery, to where they are distributed, the timeliness of the delivery, assurance that no 
illegal copies are made or distributed, that old mastercopies and replicas of the content are deleted, etcetera. Of course, 
the precise requirements of a Content Provider will vary depending on its particular business model. 

Content neutrality 

Neutrality of content delivery is important to the Content Provider. No player in the ecosystem should modify content, 
change encoding or resolution, insert advertisements or change anything similar without explicit consent from the 
Content Provider. These types of requirements are typically agreed in Service-Level Agreements with the Content 
Provider. 

Network neutrality 

Neutrality of content delivery is also important to the Content Consumers. Players in the content-delivery ecosystem 
should not misuse an acquired or natural monopoly on aspects of the delivery to unfairly discriminate other players. For 
example, a company that happens to have a local monopoly on network services should not be allowed prohibitive 
pricing the delivery of content generated and/or served by other companies. This type of requirements are typically 
regulated by law and maintained by an independent regulator and/or competition authority. 
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Collaborating CDN Service Providers ^ CDN Interconnection 

Although CDN Service Providers are typically each other's competitors, there are also cases where CDN Service 
Providers may want to collaborate. Here are some examples: 

• A CDN Service Provider may have insufficient server capacity to handle a special event or a specific large 
order. The CDN Service Provider could commission the capacity of other CDN Service Providers as back-up 
for such occasions. 

• A global CDN Service Provider could commission a local CDN Service Providers to locally deliver content in 
order to achieve more cost-efficient content delivery in a specific region. 

• Local CDN Service Providers could team up and have a joint venture to increase their delivery footprint, 
competing with global CDN Service Providers over large Content Provider accounts. 
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Annex D (informative): 
Advanced use cases 

D.1 General 

This annex presents advanced use cases and concepts that are not further addressed in the present document. 



D.2 Caching - CDN Interconnection 

Some telecom operators and Internet Service Providers deploy caching servers, a.k.a. "transparent caching" servers, in 
their IP networks in order to cache content mainly distributed by CDNs over Internet, with as goal to relax and balance 
the load on their IP networks. 

Today in most situations the two overlay networks - the Upstream CDN and the Downstream set of transparent caching 
servers - run independently from each other. There is no specific interconnection interface between the two overlay 
networks. 

There could be some interest to set up interfaces between these overlay networks (of course on condition that their 
owners get the right business incentives for). 

Here are two illustrations of the potential benefits (this is not an exhaustive list): 

• Setting up an interface between the two overlay networks could be beneficial for providing the Upstream CDN 
(and beyond the Content Provider) with useful logging, monitoring and reporting data. 

• Setting up an interface between the two overlay networks could be beneficial for allowing the Upstream CDN 
to request that a given content file be purged from, or invalidated in, any Downstream caching server. 

The first difference with the "standard" CDN interconnection use case introduced in clauses Al, A2, A3 is about 
resolving content location (see clause 6.7). In this "caching-CDN" interconnection use case, the CDN Interconnection 
solution shall allow the Downstream set of caching servers to intercept and handle the Consumer request (i.e. without 
this request being first redirected by the Content Provider or the Upstream CDN). 

NOTE 1: Once such specific interfaces are set up between the Upstream CDN and the Downstream set of 

transparent caching servers, the latter ones cannot be any more considered as fully transparent, at least 
from the viewpoint of the Upstream CDN. This should therefore call for a slight evolution of the 
terminology. 

NOTE 2: Regulatory aspects may impact transparent caching feasibility. 



D.3 Information-centric networking and CDN 
interconnection 

D.3.1 Background 

CDN interconnection has similar goals and use cases to Information-Centric Networking (ICN). This relation could 
affect the work of ETSI MCD on CDN interconnection, so an informative discussion is provided here. First, a very brief 
description of CDNs and ICN is given in order to set the background. Then, similarities and differences in terms of 
objectives, technical approach, deployment and business models are discussed. Finally, the possibility of interaction and 
coexistence of ICN and CDN in a future Internet is discussed. CDNs are real working systems, while ICN is still at the 
research stage. The reader should note that the analysis below is based on the state of ICN research and the assumption 
that ICN will eventually meet its design goals. 
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A CDN is a privately owned overlay network that aims to optimize delivery of content from Content Providers to 
Consumers. CDNs are usually independent of each other. Optimization is in terms of performance, availability and cost. 
CDNs operate by serving content to Consumers from managed caches - called surrogates - at the edge of the network. 
CDNs may also use reserved network resources. In this case, the CDN Provider collaborates with Network Operators on 
surrogate placement and network resource reservation. The deployment, extension and (part of) the operation of CDNs 
are centrally managed. To maintain transparency for Consumers, normal content locators (e.g. URLs) are used to access 
content. However, the CDN treats those locators as simple content identifiers when selecting a surrogate, in effect, 
decoupling the locator from the content location. 

ICN shares many of the goals of CDNs. Optimization of delivery with ICN usually entails caching, QoS -aware routing 
and traffic differentiation, to various degrees. Unlike CDNs, ICN aims at operating natively at the network level 
(although operation as an overlay is also possible). A Network Operator deploys ICN-enabled elements (mainly routers) 
with minimal planning in terms of content demand. The reach of ICN grows without any central management as each 
Network Operator becomes ICN-enabled. For content access, ICN uses explicit content identifiers that are independent 
from the content location. 

A CDN constitutes an administrative domain, whereas in ICN an administrative domain can be as granular as an ICN 
router. When viewed in terms of administrative domains, CDN interconnection resembles the interconnection of ICN 
elements/domains. The interconnection of ICN domains is itself an Information-Centric Network, as the interconnection 
of CDNs is still a CDN. 

D.3.2 Comparison of ICN and CDNs 
D.3.2.1 Objectives 

A main objective of both CDNs and ICN is the effective delivery of content from Content Providers to Consumers. ICN 
also aims at accommodating end-users who can be both Consumers and Content Providers. The decoupling of content 
identifiers from the content location is an explicit goal in ICN, while in CDN this is a by-product. 

D.3.2. 2 Technical approach 

The main elements of a CDN are a set of content servers and a request redirection system. The content servers are 
carefully placed to be close to the Consumers and can be populated prior to any requests based on foreseen demand. A 
Consumer requests content with a normal URL, which triggers a part of the redirection system that resides at the 
seeming location of the content. The redirection system selects a content server based on criteria aiming to optimize 
some aspect of the delivery task. The selected content server then delivers the requested content to the Consumer. 

In ICN, any edge router with storage capabilities can act as a content server, which is populated based on actual 
demand. Alternatively, or in addition, QoS-aware routing and traffic differentiation techniques are used to establish a 
path from the content source to the Consumer. Content is requested with a dedicated identifier. This identifier can be 
used to route the request to the content source or to an intermediate content server, while constructing the path. 
Alternatively, the identifier can be used as an index in a directory system to retrieve content metadata. The metadata are 
then used to setup a path from the content source to the Consumer. 

D.3.2.3 Deployment 

A CDN is deployed as an overlay with all its elements independent from Network Operators and belonging to the same 
CDN Provider. The CDN Provider works closely with the Content Provider in order to ingest and place content. There's 
also close collaboration between the CDN Provider and the Network Operators for server placement and reservation of 
resources. Once the CDN is operational, any unforeseen change in Content Provider requirements, network conditions 
or Consumer demand will force the CDN Provider to re-design the deployment. To avoid this, CDNs are designed with 
over-provisioning and redundancy. 

On the other hand, ICN is deployed as Network Operator infrastructure. Each Network Operator owns and 
independently manages the ICN elements in its domain. There's no "ICN Provider" to oversee the deployment of ICN. 
The system grows as each Network Operator becomes ICN-enabled. In order to use ICN, Content Providers need to 
provide content source servers and content metadata. ICN is designed with flexibility in mind, which permits handling 
of unforeseen events. 
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D.3.2.4 Business models 

In a typical business case for CDNs, a CDN is deployed in a Network Operator domain and the Network Operator acts 
both as a CDN Provider and as a Content Provider. Network Operators use this model to offer content services, such as 
IPTV, to their customers and so to differentiate their business. In another model for CDNs, a CDN Provider agrees with 
several Network Operators to deploy content servers and reserve resources in their domain. The CDN Provider, e.g. 
Akamai, then sells content delivery services to interested Content Providers. 

The ICN business model is very similar to that for connectivity services. A Network Operator deploys ICN in its 
domain and makes transit or peering agreements with other ICN-enabled Network Operators. The Network Operator 
then offers content delivery services to Content Providers. It is also possible for the Network Operators to offer content 
consumption premium services to its customers. 

D.3.3 Interconnection of ICN and CDNs 

In a future Internet where ICN is deployed by only some Network Operators, it would be difficult to meet end-to-end 
the ICN performance goals. This is because those domains that have not deployed ICN would create gaps in the 
Information-Centric Network. In such a case, CDNs can act as overlay bridges, because they might already have 
content close to the downstream ICN domain. In essence, CDN Providers would become Content Providers for ICN. 
However, the incentive for the CDN Provider is unclear, because such a move could undermine its own content delivery 
service. Borrowing from the motivation for the interconnection of CDNs, a CDN Provider who wants to extend its 
reach, instead of interfacing with a neighbouring CDN, could interface with an ICN-enabled Network Operator. This is 
of course a scenario that only market forces and time can validate. 
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